OpenEdge Development:<br />Progress Dynamics Administration Prepare schema and data files

Release 10.1A: OpenEdge Development:
Progress Dynamics Administration

Prepare schema and data files

Every deployment should be able to build the databases from scratch for a new user and also bring existing databases up to the latest version. Therefore, you must prepare the following files from your central Repository and application databases:

A full schema definition (.df) file.

Complete data (.d) files.

Incremental schema definition (.df) files.

Dataset (ADO) files.

Note: For DCU deployments, you should follow the Progress Dynamics naming conventions for .df files as shown in OpenEdge Development: Progress Dynamics Repository Reference .

The DCU uses the full .df file and the .d files to create a new database. Because .d files load faster than ADOs, you should use .d files when loading data into a new database. However, the data in ADOs is independent of the database’s session properties. When using .d files, you must take into account those session properties.

The DCU uses the OpenEdge defaults for the session properties listed in Table 5–5.
Table 5–5: DCU session properties
Property

Default value
DATE-FORMAT 
MDY 
YEAR-OFFSET 
1950 
CODEPAGE 
UTF-8 
When creating files for your deployment, you should set these properties to the values for the environment for which you are creating the deployment. Then, you should customize a DCU session to use the same values. For more information on setting session properties, see the information on creating session properties in Chapter 2, " Defining and Managing Sessions."

For more information on creating .df and .d files, see OpenEdge Data Management: Database Administration .

Remember that it is best to create these files from a clean copy of your Repository and application databases. Make all the changes you can on your central databases and then deploy those changes to your users through ADOs. In general, you should only run fix programs during a user deployment if absolutely necessary. If the changes can be done on the central databases and the results deployed as ADOs, do it that way.